Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Textfiles/coloredbooks/RedBookv2.sit.hqx/Red Book v2

Text File | 1997-11-17 | 122KB | 3,437 lines

TRUSTED NETWORK INTERPRETATION ENVIRONMENTS GUIDELINE






NCSC-TG-11


Library No. 5-235,465


Version 1
TRUSTED NETWORK INTERPRETATION ENVIRONMENTS GUIDELINE

FOREWORD



The National Computer Security Center is issuing the  Trusted
Network Interpretation Environments Guideline as part of our Technical
Guidelines Program, through which the "Rainbow Series"
is produced. The Technical Guidelines Program ensures that the
features of the Trusted Computer Systems Evaluation Criteria (DOD
5200.28-STD) are discussed in detail and that guidance is provided
for meeting each requirement. The National Computer Security Center,
through its Trusted Product Evaluation Program, analyses the security
features of commercially produced and supported computer systems.
Together, these programs ensure that organisations are capable
of protecting their important data with trusted computer systems.


The Trusted Network Interpretation Environments Guideline is a
companion to the Trusted Network Interpretation of the. Trusted
Computer System Evaluation Criteria (NCSC-TG-O5),  published 31
July 1987.  The  Trusted Network Interpretation Environments Guideline
provides insight into the issues relevant when integrating, operating,
and maintaining trusted computer networks. This document identifies
the minimum security protection required in different network
environments such that network certifiers,  integrators, and accreditors
can determine what protection mechanisms and assurances are mmimally
required in specific network environments.


This document parallels Computer Security Requirements - Guidance
for Applying the Department of Defense Trusted Computer System
Evaluation Criteria in Specific Environments (CDC-STD-O3-85) and
its technical rationale (CSC-STD-04-85). It also provides a descriptive
presentation of the security issues that exist in networked computer
systems as the networked computer system environment is inherently
more complex and requires additional protection considerations
over stand-alone computer systems.


As the Director, National Computer Security Center, I invite your
suggestions for revising this document. We plan to review this
document as the need arises.

 • PATRICK R. GALLAGHER JR.
 1 August 1990
 • Director
 • National Computer Security Center





ACKNOWLEDGMENTS



The  National  Computer  Security Center extends special recognition
and acknowledgment for their contributions to this document to
Dr. Marshall D. Abrams, Renee Child, Annabelle Lee, Dr. Jonathan
K. Millen, Samuel I. Schaen, and Dr.  Martin W. Schwartz, of The
MITRE Corporation, as authors; Richard Wilmer, also of The MITRE
Corporation, as technical editor; and to Alfred Arsenault, David
Chizmadia, id Rick Siebenaler of the National Computer Security
Center, who managed the effort ad participated in the development.


Special thanks are extended to the many members of the computer
security community who enthusiastically gave their time and expertise
in reviewing the material and providing valuable comments and
suggested changes.  Special thanks are extended to James P. Anderson
of James P. Anderson Co., Donald L. Brinkley of Gemini Computers,
Inc., Dr. Eric Roskos of The Institute for Defense Analysis, Dr.
Tien Tao of Gemini Computers, Inc., and Dr. John M. Vasak of The
MITRE Corporation for their extensive suggestions and recommendations.
1 Introduction



This Trusted Network Interpretation (TNI) Environments Guideline
(TNIEG) addresses many issues in determining the security protection
required in different network environments.  It complements the
TNI, just as the Trusted Computer System Evaluation Criteria (TCSEC)
Environments Guideline [1] complements the TCSEC.  The TNI interprets
the TCSEC for networks; it contains all of the criteria in the
TCSEC, adding interpretation and rationale to applying trust technology
to network systems. In the same way that the TCSEC Environments
Guideline provides gnidance on applying the TCSEC, this TNIEG
provides gnidance on the use of the TNI. The TCSEC and its Environments
Guideline constitute the foundation on which the TNI and TNIEG
add network applicability.
1.1 Background



The National Computer Security Center (NCSC) is responsible for
establishing and maintaining technical standards and criteria
for the evaluation of trusted computer systems. As part of this
responsibility, the NCSC is developing guidance on how new security
technology should be used. Two objectives of this guidance are:

 •  Establishing a metric for categorizing systems according
to the security protection they provide, and
 •  Identifying the minimum security protection required
in different environments.




The TCSEC [2] helps to satisfy the first objective by categorizing
computer systems into hierarchical classes based on evaluation
of their security features and assurances.  The TCSEC Environments
Guideline [1] helps to satisfy the second objective by identifying
the minimum classes appropriate for systems in different risk
environments. These two documents, however, apply to stand-alone
corn puter systems.


The TNI [3] satisfies the first objective by interpreting the
TCSEC for networks.


The TNI also provides guidance for selecting and specifying other
security services (e.g., communications integrity, denial of service,
transmission security). The TNIEG is the first step toward addressing
the second objective.


TNI Environments Guideline
    Introduction
1.2 Trusted Network Technology Publications



The NCSC has decided to provide guidance concerning security in
networks and distributed Automated Information Systems (AISs)1
in a series of publications. The subject area is collectively
identified as Trusted Network Technology (TNT). The TNI is the
first TNT publication. This TNIEG is the second TNT publication.
It contains the best guidance that is available at this time;
as technology advances and more experience is gained in implementing
trusted networks, more specific guidance will be provided. This
TNIEG provides elaboration and clarification on the TNI. Guidance
concerning Interconnected AIS which initially appeared in the
TNI, Appendix C, has been revised and incorporated into this document
(see Section 6 and Appendix A).  This document does not address
all of the security issues that are excluded from the TNI. Other
topics, such as composing a trusted system from evaluated components,
will be discussed in future TNT publications.
1.3 Purpose



The overall purpose of this TNIEG is to assist program managers,
integrators, certifiers, and Accreditors with identifying the
minimum security protection needed for different trusted computer
network environments. For brevity, this audience is referred to
as security managers. Not all questions can be answered at this
time. The NCSC invites suggestions for topics to be addressed
in future TNT publications.


This guideline is not a tutorial on security and networking; it
is assumed that the reader will have some background in both areas.
Suggested background references are identified in Appendix B.
This guideline is designed to be self contained; a fair amount
of background information that can be found in the TNI is also
included here. The interested reader may consult the TNI and other
documents referenced in this guideline for further detail.
1.4 Scope



This document describes an environmental assessment process that
helps determine the minimum level of trust recommended for a specific
network operational environment. The primary focus of this document
(and also of the TNI) is on the AIS 1Definitions of terms particularly
important to this document are given in Section 2.


 TNI Environments Guideline
     Introduction


hardware, firmware, and software aspects of security; therefore,
neither this guideline nor the TNI address all the security requirements
that may be imposed on a network.  Depending on the particular
environment, communications security (COMSEC), emanations security
(TEMPEST), physical security, personnel security, administrative
security, and other information security (INFOSEC) measures or
safeguards are also required. This document applies to networks
that are entrusted with the processing of information, regardless
of whether that information is classified, sensitive, or otherwise
relevant to national security.
1.5 Structure of the Document



Section 2 of this document defines terms and Section 3 discusses
Network Security Architecture and Design. Section 4 guides security
managers in applying Part I of the TNI; Section 5 does the same
for Part II. Section 6 addresses security issues that arise when
AIS are interconnected. Appendix A discusses the Cascade Condition
in greater detail; Appendix B provides tutorial and background
references on network security; and Appendix C discusses encryption
and encryption mechanisms.
2 Terminology



Many of the terms used in the TNI are drawn from diverse specialization
areas.


Their special meaning in context may differ from common English
usage. In this section we explain how such terms are used in the
TNI and how these definitions have been refined in this document.
Terms are printed in boldface when they are defined.
2.1 Automated Information System



An AIS is defined in DODD 5200.28 as "an assembly of computer
hardware, software, and/or firmware configured to collect, create,
communicate, compute, disseminate, process, store, and/or control
data or information" [4]. This is both a broad definition
and a new one, since DODD 5200.28 was published after the TNI.
 The TNI states that "automatic data processing (ADP) systems,
referred to in this [TNI] document as Automated Information System
(AIS)...", and equates AIS and ADP.  We will use the DODD
5200.28 definition since it is broader and more authoritative.
We also note that DODD 5200.28 tends to pluralize AIS as AISs
while the TNI considers AIS to be a collective noun.  We have
followed the latter convention.
2.2 Network Trusted Computing Base



The Network Trusted Computing Base (NTCB) is the totality of protection
mechanisms within a network system2-including hardware, firmware,
and software-the combination of which is responsible for enforcing
a security policy. The NTCB is the network generalization of the
trusted computing base (TCB). An NTCB Partition is the totality
of mechanisms within a single network subsystem3 for enforcing
the network policy, as allocated to that subsystem; it is the
part of the NTCB within a single network subsystem.


The distinction between a system and a subsystem is a matter of
the viewpoint of the ob-server. One observer's system may be another
observer's subsystem. For example, the ven-dor of a local area
network may regard his product as a system, while the customer's
network architect may consider it to be a subsystem along with
hosts, workstations, etc.  ~e THI uses component in the definition
of NTCB Partition. We use subsystem to be con-sistent in this
document.


TNI Environments Guideline
     Terminology
2.3 System and Component



The terms  system  ad  component need  to be related  to  each
 other.


Unfortunately, the TNI is not completely consistent in its use
of these terms. We will first cite the relevant sections from
the TNI; then we will reconcile them as used in this guideline.
As discussed below, we define the relationship as follows: A component
is a physical unit contained within a system.
2.3.1 TNI Introduction (definition not used in TNIEG)



The TNI Introduction states (emphasis added):


A network system is the entire collection of hardware, firmware,
and software necessary to provide a desired functionality. A component
is any part of a system that, taken by itself, provides all or
a portion of the total functionality required of a system. A component
is recursively defined to be an individual unit, not useful to
further subdivide, or a collection of components up to and including
the entire system.
2.3.2 TNI - Appendix A (definition not used in TNIEG)



Appendix A of the TNI presents the view:


a trusted network represents a composition of trusted components....
 The approach to evaluation of a network suggested by this view
is to partition the system into components, rate each component
to determine its security-relevant characteristics, and then evaluate
the composition of the components to arrive at an overall rating
class for the network. This approach ... allows for the evaluation
of components which in and of themselves do not support all the
policies required by the TCSEC, ...  contribute[s] to the overall
evaluation of any network which uses them and allows for the reuse
of the evaluated component in different networks without the need
for a re-evaluation of the component.


Appendix A goes on to state that:


The set of policy-related features to be supported by the c'omponent
need not be the complete set required for a stand-alone system:
features not supplied by one component for the system are supplied
by another.
2.3.3 Discussion



We see a difference between the Introduction and Appendix A of
the TNI. We


will use the definition of component as an individual unit that
does not provide acomplete set of end-user services. As a consequence,
a subsystem can operate on its own and a component will require
an external connection to perform a useful function.


TNI Environments Guideline
     Terminology


Appendix C of the TNI uses component, as follows, where we would
use subsystem:


Any AIS that is connected to other AIS must enforce an "Interconnection
Rule" that limits the sensitivity levels of information that
it may send or receive. Using the component connection view, each
component responsible for maintaining the separation of multiple
levels of information must decide locally whether or not information
ca be sent or received.


A component may support all the policy and accountability requirements:
M, D, I, ad A4; however, as defined above, this is not applicable
to determining whether an individual unit is a component. A component
which supports some part of the security policy contains an NTCB
partition. In the extreme, a component may not have any security-relevant
function; in this case it doesn't support any TCSEC policy and
doesn't contain an NTCB partition.
2.3.4 Definitions



To summarize the previous discussions, following are definitions
for component ad system/subsystem.

 •  Component: An individual physical unit that does not
provide a complete set of end-user services.
 •  System/suhsystem:  A  collection of hardware,  firmware,
 and  software necessary configured to collect, create, communicate,
compute, disseminate, process, store, and/or control data ad information
[4].





2.4 Evaluation



NCSC-evaluation refers specifically to the process in which the
NCSC determines whether a commercial-off-the-shelf (COTS) product
satisfies the TCSE~C. Application of the TCSEC to a particular
product may be assisted by an interpretation guideline such as
the TNI [5]. In such a case, the guideline clarifies the meaing
of the TCSEC's language with regard to a particular type of product,
but in no case circumvents or grants exception to the requirements
of the TCSEC.  The purpose of an NCSC-evaluation is as follows:


4M:datory access control, discretionary access control, identification
and authentication, and audit, respectively.


TNI Environments Guideline
     Terminology


The primary goal of the NCSC is to encourage the widespread availability
of trusted computer systems. This goal is realized, in large measure,
through the NCSC's Commercial Product Evaluation Program.  This
program is focused on the technical evaluation of the protection
capabilities of off-the-shelf, commercially produced and supported
systems that meet the computer security needs of government departments
and agencies.  This product evaluation culminates in the publication
of an Evaluated Products List (EPL) report... [6].


An NCSC~valuation places a product in one of four divisions: D,
C, B, or A.


Division D is for systems that have been evaluated but fail to
meet the requirements for a higher NCSC~valuation rating.  Division
C has two classes:  C1 and C2, which require discretionary (need-to-know)
protection. Division B has three classes: B1, B2, and B3, which
require support for sensitivity labels and increasing robustness
of system architecture.  Division A has only class Al, which requires
additional assurance through formal verification methods.
2.5 Certification



Certification is defined as "the technical evaluation of
a system's security features, made as part of and in support of
the approval/accreditation process, that establishes the extent
to which a particular system's design and implementation meet
a set of specified security requirements" [7]. In this definition,
the word evaluation is used in the generic sense and should not
be confused with NCSC valuation. The primary distinction is that
certification is an evaluation with respect to specified requirements,
ad NCSC~valuation is an evaluation against the TCSEC (and the
TNI).


Certification is conducted in support of the accreditation decision.
 For most systems, the hardware, system software, applications
software, communications equipment, and the operational facility
must be configured and tested during certification. Certification
should be performed by technical personnel independent of the
development organization, according to an acceptable methodology.
Certification should identify the level of security protection
with regard to a procedure, program, or system.  Certification
results in the issuance of the Certification Statement, which
states whether system security requirements are met, describes
all known remaining vulnerabilities, and advises the Accreditor
relative to the accreditation decision. If requirements are not
met, the Certification Statement lists problem areas and identifies
suggested solutions (if known).  A certification documentation
package, called the Certification Report of Findings, submitted
to the Accreditor includes the Certification Statement, certification
analysis, resuils of Security Test and Evaluation, id results
of Operational Test and Evaluation.
2.6 Accreditation



Accreditation is "the managerial authorization and approval
granted to an ADP system or network to process sensitive data
in an operational environment, made on the basis of a certification
by designated technical personnel..." [3]. Accreditation
is a management decision to operate a system or network employing
specific safeguards, against a defined threat, at an acceptable
level of risk, under a stated operational concept, with stated
interconnections, in a specific operational environment, with
a specific security mode of operation. Other terms have been used
to identify the formal managerial approval for operation; in this
document we use the term Accreditation.  FIPS PUB 102 defines
Accrediting Officials as "the agency officials who have authority
to accept an application's security safeguards and issue an accreditation
statement that records that decision. The Accrediting Officials
must also possess authority to allocate resources to achieve acceptable
security and to remedy security deficiencies" [7]. The ultimate
responsibility for system security rests with the Accreditor.
DODD 5200.28 employs the term Designated Approving Authority (DAA)
to refer to the same officials or officers [4].


All AIS must be accredited before they may process or use sensitive
or classified information, unless a written waiver is granted
by the Accreditor. Accreditation is based on a technical investigation
and a formal review of the certification Report of Findings. Before
authorizing an AIS to operate, the Accreditor must ensure that
satisfactory security measures have been installed and that any
residual risk is within acceptable limits. Often, the Accreditor
must weigh the technical shortcomings of an AIS against operational
necessity. Lacking other ways to accomplish an operational mission,
the Accreditor may determine that it is preferable to accept a
residual security risk than to preclude the mission. To ensure
that the accreditation goals and objectives are adequately met,
the Accreditor must be involved throughout the system life cycle.
2.7 Two Types of Networks



A network may be defined as either an interconnection of accredited
AIS or as a Unified Network. When it is not necessary to differentiate
in this guideline, the term network is used.
2.7.1 Unified Networks



The TNI defines a Network Single Trusted System while DODD 5200.28
Enclosure (5) defines a Unified Network; this TNIEG conforms to
the latter usage.


The section of Enclosure (5) that addresses Unified Networks is
brief and instructive5:


Some networks may be accredited as a whole without prior accreditation
of their component AIS. It is necessary to treat a network as
unified when some of its AIS subsystems are so specialized or
dependent on other subsystems of the network for security support
that individual accreditation of such subsystems is not possible
or meaningful with respect to secure network operation.  In order
to be accredited, a Unified Network shall possess a coherent network
architecture and design, and it should be developed with an attention
 to   security  requirements,  mechanisms,   and  assurances commensurate
with the range of sensitivity of information for which it is to
be accredited.


The recommended approach for accrediting a Unified Network is
to apply Enclosure  4  to  the  entire  network  to  derive  an
 evaluation  class.  Requirements to meet that evaluation class
then are obtained from an applicable interpretation of DoD 5200.28-STD
[the TCSEC], such as NCSC-TG~05 [the TNI].
2.7.2 Interconnected Accredited AIS



Enclosure (5) of DODD 5200.28 also discusses Interconnected Accredited
AIS:


If a network consists of previously accredited AIS, a Memorandum
of Agreement6 [MOA] is required between the DAA of each DOD Component
AIS and the DAA responsible for the network ... The network DAA
must ensure that interface restrictions and limitations are observed
for connections between DOD Component AIS.  ... In particular,
connections between accredited AIS must be consistent with the
mode of operation of each AIS, the specific sensitivity level
or range of sensitivity levels for which each AIS own and a component
will require an external connection to perform a useful function
is accredited, any additional interface constraints associated
with the particular interface device used for the connection,
and any other restrictions required by the MOA


 ---------------------------


5 As mentioned in the introduction and the definitions, this TNIEG
differs from DODD 5200.28 and the TNI in the usage of AIS and
the definition of component. This quotation has been slightly
edited to conform to the usage in this guideline. she content
of a Memorandum of Agreement is discussed in Section 3.2
2.8 Network Security Architecture and Design



Network Security Architecture and Design (NSAD) applies to all
networks. The NSAD identifies how the NTCB is partitioned and
how the trusted system requirements are met. Security engineering,
including the development of the NSAD, is a specialty area within
systems engineering. The security engineer is responsible for
ensuring that the system being built meets the security requirements
of the organization.  The security engineer ensures that the AIS
security conforms to applicable regulations and policy, and implements
the system security requirements [8].


The security policy includes the set of laws, rules, and practices
that govern how an organization manages, protects, and distributes
sensitive information (including classified information). The
overall security policy is addressed in a family of related documents
consisting of a system security policy, a security policy model,
and security requirements. The system security policy is developed
first, followed by the other two.  A system security policy interprets
and applies regulations to systems. The security policy model
defines subjects and objects and the accesses between the two.
The security requirements document identifies evaluatable user
requirements for a secure system.


The security architecture is that part of the system architecture
that describes the required security services and features.  The
security architecture shows how the required level of assurance
for the system is to be met.  A mapping of security requirements
to functional elements is documented in the security architecture;
therefore, the securily architecture is used to document security
design decisions.
2.9 Protocol Layer Approach



This guideline discusses networks in terms of the Open System
Interconnection (0SI) reference model [9] because that model provides
a well-understood terminology and is used in the TNI. This guideline,
however, is independent of the actual protocol reference model
used.


274-353 0 - 90 - 2 : QL 3


TNI Environments Guideline
     Terminology


An NTCB implementation need not include all protocol layers.
The precise security services and their granularity will depend
on the highest protocol layer at which an NTCB partition is implemented.7
 For example, in a Unified Network where layer 3 (the network
layer) is the highest layer that implements the NTCB, the network
will be able to enforce mandatory access control (MAC) and discretionary
access control (DAC) decisions on the granularity of network addresses8.
The network system being evaluated knows only about the range
of classifications that the host (or other network) is permitted
to handle and the hosts (or other networks) that are permitted
to communicate with each other. Finer distinctions must be made
by the hosts (or other networks) involved. When a trusted network
provides all seven layers, the network is aware of and enforces
MAC and DAC at the granularity of individual users.


A network device might not provide a complete set of end-user
services through layer 7. Products that do not provide all system
services through layer 7 may be NCSC-evaluated as components and
subsequently used with other components to compose a network.
2.10 Part II Security Services



The terms functionality, strength of mechanism, and assurance
are used to rate TNI Part II services. Their meanings in that
context are described below.


Functionality refers to the objective and approach of a security
service; it includes features, mechanism, and performance.  Alternative
approaches to achieving the desired functionality may be more
suitable in different applications environments.


Strength of'mechanism refers to how well a specific approach may
be expected to achieve its objectives. In some cases the selection
of parameters, such as number of bits used in a checksum or the
number of permutations used in an encryption algorithm, can significantly
affect strength of mechanism. Wiih regard to inadvertent threats,
strength refers to the ability to operate correctly during natural
disasters, emergencies, operator errors, and accidents.  Inadvertent
threats are particularly


7 Since the publication of the TNI, the policy environment has
changed. "User", as defined in DODD 5200.28, ad peer.entity,
as defined in the 051 reference model, are comparable.  Therefore,
the TNIEG applies to all layers of the 051 architecture.


8 A network address refers to either a host or another network.


TNI Environments Guideline
     Terminology


critical to prevention of denial of service. As an example, for
communications line outages, strength of mechanism may refer to
the number of alternate routes that may be used to bypass the
outage.  The misdelivery of messages is an example of an inadvertent
 threat  that  may  disclose  information  to  unauthorized  individuals.
 Encryption can be used to prevent the unintended recipient from
seeing the information.


Assurance refers to a basis for believing that the functionality
will be achieved; it includes tamper resistance, verifiability,
and resistance against circumvention or bypass.  Assurance is
generally based on analysis involving theory, testing, software
engineering, validation and verification, and related approaches.
The analysis may be formal or informal.
3 Network Security Architecture and Design (NSAD)



 Every network should have a Network Security Architecture and
Design (NSAD).  This section helps the security manager in establishing
the NSAD for the network.


The NSAD, produced as part of the risk management process, documents
the security services. As mentioned in Section 1, the primary
focus of this TNIEG is on the  AIS  aspects  of  security.   Depending
 on  the  particular  environment, communications security (COMSEC),
emanations security (TEMPEST), physical security, personnel security,
administrative security, and other information security (INFOSEC)
measures or safeguards are also incorporated in the NSAD. An NSAD
results from a series of tradeoffs among cost, effectiveness,
technical risk, mission requirements, and risk management.


While the architecture part of the NSAD may be somewhat abstract,
the design part should be quite concrete. The design maps the
selected security services to system functional elements9. Next,
these functional elements are assigned to components and subsystems.
3.1 Composing an NSAD



The security manager is responsible for ensuring that an NSAD
is defined that applies to all the components or subsystems that
constitute the network. The NSAD for a network must address the
applicable security-relevant policies and may incorporate the
NSADs of its constituent components or subsystems. In some cases,
such as when a component provides part of the functionality of
the network (e.g., a local area network (LAN) providing 051 layer
three communication services), the NSAD of the component may be
incorporated with little or no change into the NSAD for the network.
The component NSAD will probably require some modification to
address the applicable policy and environment constraints.


A typical network configuration will include multiple vendor's
products. When the network is created, the security manager must
reconcile the diverse NSADs of the constituents into a coherent
NSAD for the configured network and identify any


9 Sections 4 and 5 of this document should guide the security
manager in selecting those securi-ty services and safeguards that
are appropriate for the given operational environment.


TNI Environments Guideline              Network Security Architecture
and Design


restrictions or new security services and assurance that must
be added. The NSAD must implement national, service, and command
policies for the environment in which the network will operate.
The same process applies when previously accredited AIS are to
be interconnected to support the exchange of information.


In contrast to the networks described above, when a network is
created from scratch, the NSAD may be established before any devices
are selected and may be included as part of the criteria for selecting
the network devices.


Note that the network may include components that are not security-relevant
and, therefore, do not have a component NSAD. The design decisions
that result in the inclusion of non-security-relevant components
are documented in the NSAD.


AIS may be combined into a network under conditions of a hierarchical
relationship of their security managers. In this case the NSAD
of the subordinate system must conform to the governing NSAD.
For example, when a host computer connects to a common user network,
the host computer must conform to the NSAD established by the
security manager of the common user network, who has a responsibility
to the security managers of all other connected AIS to maintain
the network's trustworthiness.  As discussed below, this conformance
is recorded in a Memorandum of Agreement (MOA).


AIS whose security managers are not hierarchically related may
also be combined to form a network. In this case, the security
managers come to agreement on the NSAD for the network; this agreement
is also recorded in an MOA.
3.2 Memorandum of Agreement



If a network consists of previously accredited AIS, a MOA is required
between the Accreditors for each subsystem. This MOA is part of
the documentation of the NSAD. The MOA discusses the accreditation
requirements for each subsystem that is to be interconnected to
form the network [4], i.e., defines all the terms and conditions
of the security arrangements that will govern the operation of
the network [10]. The objective of the MOA is to document the
interconnection requirements and identify any requirements that
may be necessary to provide overall security safeguards for the
entire network. This network includes all the interconnected subsystems,
the communications devices, the usei-s, and the data stored in
the subsystem


[10].  A Memorandum of Record (MOR) is used when the subsystems
have the same Accreditor. A comprehensive M0A10 could constitute
the entire NSAD for a network; alternatively, the MOA could contain
high level agreements, with the details spelled out in supporting
documents.  Following is a list of suggestions for the contents
of the MOA and supporting documents. The items towards the top
of the list are more likely to occur in the MOA; those towards
the end of the list are more likely to occur in supporting documents.

 •  A general description of the information that will
be transmitted to the network by each subsystem
 •  A summary discussion of the trusted behavior that is
expected from each subsystem
 •  The details of the overall security plan for the network
and the assignment of responsibility for producing and accepting
the plan
 •  A description of the overall network security policy
 •  A description of additional security training and assignment
of training responsibility
 •  Specification of the security parameters that are to
be transmitted between communicating subsystems
 •  A discussion of security details that are relevant
to the exchange of information among the subsystems.
 •  A description of the user community, including the
lowest clearance of any user who will have access to the network
 •  Any special considerations for dial-up connections
to any subsystem in the network, including potential security
threats and the safeguards that will be used.
 •  A description of the security protections provided
by the data communications, both local to a subsystem and between
communicating subsystem







________________


10 In this guideline, NOA is used to identify the agreement between
Accreditors and includes the NOR.


TNI Environments Guideline              Network Security Architecture
and Design

 •  A description of the information that each subsystem
will log in the audit trail, and how the audit trail tasks will
be divided among the subsystems
 •  A description of the information security services
to be offered to the network by each subsystem, including:
 •  The types of processing provided by each subsystem,
e.g., file query, individual user, general processing
 •  The modes of operation of all the subsystems, e.g.,
dedicated, system high, multilevel
 •  The sensitivity levels processed on all subsystems





4 TNI Part I Security Requirements



This section assists the security manager in determining the recommended
minimum security requirements based on TNI Part I and Appendix
A, which interprets the TCSEC for networks.


The procedure for determining the minimum security requirements
for a network parallels the procedure for a stand-alone system,
whereby the highest classification of data and the lowest clearance
among system users are used in computing a risk index.  The risk
index is used to determine which NCSC~vaIuation rating is required
of the system to provide adequate security.  To emphasize, these
are the minimum requirements. The TCSEC Environments Guideline
does not address environmental factors such as the number of users
and the percentage of users at different classification levels.
 These factors may become more significant in a network environment.
Communications security risk in a network is addressed by the
National Security Agency (NSA) and other cognizant organizations
and results in a set of recommendations for the appropriate equipment
or security procedures. Other factors, such as the number of connections,
the physical distance between devices, the number of subsystems,
the presence of encryption, and the possible presence of intervening
systems between the resources being used and the ultimate user
may result in more or less stringent requirements.
4.1 Risk Management



Risk management is a methodology used to identify, measure, and
control events which adversely affect security; it involves cost-benefit
analyses to ensure appropriate cost~ffectiveness of security safeguards.
A risk management program is mandated by Enclosure (3) of DODD
5200.28.


The literature on risk management is quite extensive. It is not
the ;Purpose of this document to survey the field. The interested
reader is referred to FIPS PUB 65 [11].  The literature is constantly
growing; a recent high-level introduction to general concepts
and terminology can be found in Bell [12] and in the Proceedings
of the First Invitational Workshop on Computer Security Risk Management
[13].


DODD 5200.28 Enclosure (4) mandates the use of a methodology,
extracted from


the TCSEC Environments Guideline, to determine the recommended
evaluation class


TNI Environments Guideline                    TNI Part I Security
Requirements


(or requirements of an evaluation class) based on a specific environment.
Enclosure (5) of the Directive also recommends this method to
determine minimum computer-based requirements in a network. This
guideline also uses that method. Use of a different method requires
prior approval of the Assistant Secretary of Defense (ASD) Command,
Control, Communications, and Intelligence (C31).


DODD 5200.28 Enclosure (4) contains six major steps in the risk
assessment procedure. These steps are listed below. DODD 5200.28
Enclosure (4) applies in all steps.


Step 1. Determine system security mode of operation.


Step 2. Determine minimum user clearance or authorization rating.


Step 3. Determine maximum data sensitivity rating.


Step 4. Determine risk index.


Step 5. Determine minimum security evaluation class for computer-based
controls.


Step 6. Determine adjustments to computer security evaluation
class required.


An elaboration of step six given in Migues [14], involving a detailed
analysis of both environmental and architectural risk factors,
is based on Landwehr and Lubbes [15]. It presents a method which
incorporates analysis of the applications environment.  This analysis
includes such factors as whether the system allows programming,
or whether it is restricted to a limited set of applications.
This more detailed information supports a finer determination
of the level of trust required.
4.2 Determination of Network Risk



To apply the TCSEC Environments Guideline guidance, the security
manager must determine the following:

 •  minimum clearance or authorization of the network usefs
(see Table 1 11),







TNI Environments Guideline                    TNI Part I Security
Requirements


Table 1


Rating Scale for Minimum User Clearance ~m1n)

Minimum User Clearance               Rmin

Uncleared OR Not Authorized (U)      0

Not Cleared but Authorized Access    1
to Sensitive

Confidential

Secret(S)                            3

Top Secret (TS) and/or current       4
Background Investigation (BI)

TS and/or current Special            5
Background Investigation (SBI)

One Category (IC)                    6

Multiple Categories (MC)              7








 •  maximum sensitivity of data processed by the network
(see Table 2) (the TCSEC Environments Guideline distinguishes
between an open system and a closed system based on whether application
development was done by cleared or uncleared users; the distinction
was dropped in DODD 5200.28 and is not used here either).



 • The number derived from Table 1 is used for Rmin; the one
derived from Table 2




is used for Rmax.  A risk index for the network is calculated
using the following formula:


Risk Index = Rmax - Rmin


TNI Environments Guideline                    TNI Part I Security
Requirements

 • Table 2
 • Rating Scale for Maximum Data Sensitivity ffm:)






Maximum
Sensitivity
Rating
 Maximum Data
           Rating

Ratings without     (Rmax)             Sensitivity         (Rmax)

categories          with categories
                   1,2

Unclassified U     0                  N/A 3

Not Classified     2
but    1       N
with one or more
Categories

Sensitive N

Confidential C     3
    2         C
with one or more
Cate ories

Secret (S)          4
 3         S with
one or more
Categones

only one Category
containing S

S with two or      5
more Categories

containin S

Top Secret (TS)     6
    5 5       TS
with one or more
Categories

only one Category
containing S or
TS

TS with two or     7
more Categories

containin S or TS






1 Where the number of categories is large or where a highly sensitive
category is involved, a higher rat-ing might be warranted.


2 The only categories of concern are those for which some users
are not authorized access.  When counting the number of categories,
count all categories regardless of the sensitivity level associated
with the data. If a category is associated with more than one
sensitivity level, it is only counted at the highest level. Systems
in which all data are in the same category are treated as without
categories.


3 Unclassified data by definition may not contain categories.


4 Examples of N data include financial, proprietary, privacy,
and mission-sensitive data. In some situa-tions (e.g., those involving
extremely large financial sums or critical mission-sensitive data),
a higher rat-ing may be warranted. This table prescribes minimum
ratings.


5 The rating increment between the Secret and Top Secret data
sensitivity levels is greater than the in-crement between other
adjacent levels. This difference derives from the fact that the
loss of Top Secret data causes EXCEPTIONALLY GRAVE damage to U.S.
national security, whereas the loss of Secret data causes SERIOUS
damage.


THI Environments Guideline                    TNI Part I Security
Requirements

 • Table 3
 • Security Risk Index






Risk Index               Security Mode             Minimum Security Class
                                                   4

0                        Dedicated                 No Minimum Class 1 2

0                        System High               C2  2

1                        Multilevel Partitioned    B1  3

2                        Multilevel Partitioned    B2

3                        Multilevel                B3

4                        Multilevel                A1

5                        Multilevel                *

6                        Multilevel                *

7                        Multilevel                *






1 Although there is no prescribed minimum class, the integrity
and denial of service requirements of many systems warrant at
least class C2 protection.


2 Automated markings on output must not be relied on to be accurate
unless at least class B1 is used.


3 Where an AI$ handles classified or compartmented data and some
users do not have at least a Confi-dential clearance, or when
there are more than two types of compartmented information being
handled, at least a class B2 is required.


4 The asterisk (*) indicates that computer protection for environments
with that risk index is considered to be beyond the state of current
computer security technology.


5 Most embedded systems and desk top computers operate in the
dedicated mode.


Table 3 12 is used, along with the Risk Index calculated above,
to determine a minimum NCSC-evaluation rating for the system.
Note that some terms that appear m the TCSEC Environments Guideline
are no longer defined in DODD 5200.28.  (Limited Access Mode,
and Compartmented Mode fall under the heading of Partitioned Mode.
Controlled Mode comes under the heading Multilevel. The prevt.ou:sly
used terms referred to the equivalent of the BI and B2 evaluation
classes. In DODD 5200.28, Partitioned Mode is used in place of
Compartmented Mode.)


____________________


12 Table 3 is adapted from the TCSEC Environments Guideline
5 TNI Part II Security Requirements



This section contains a discussion of TNI Part II which describes
qualitative evaluations of security services in terms of functionality,
strength of mechanism, and assurance. Part II of the TNI describes
additional security concerns and services that arise in conjunction
with networks, but that do not normally arise in stand-alone computers.


Part II of the TNI focuses on those threats that occur between
end systems (hosts) on the network. These security services include
protection against compromise, denial of service, and unauthorized
modification.  In discussing these services, the TNI borrows heavily
from the International Standards Organization (150) 051 Basic
Reference Model [9] and Security Architecture [16]. The services
discussed are closely related to those found in the latter reference.
The TNI goes beyond the 051 Security Architecture in several respects.
First, the 051 document does not address the relative strengths
of different mechanisms nor the assurances that they operate as
intended.  Second, the protection against denial of service threats
is not specifically addressed by 051 but is an important consideration
in the TNI.
5.1 Relationship of TNI Part II Services to Part I and Appendix
A


 • The Part II services are not as well understood as the features
in TN1 Part I. The fact that Part 11 services have not been supported
by equally well developed theories and detailed evaluation criteria
should not be interpreted to imply that their security problems
do not have to be evaluated as rigorously as TNI Part I and Appendix
A services. Some Part II services may not be part of the NTCB.
For example, to make the NTCB as small as possible, some of the
protocol software may be outside the NTCB. Therefore, the protocol-based
protection against denial of service is likely to be outside the
NTCB. Nonetheless, it must rely on some of the fundamental NTCB
assurances since the protocols invoke portions of the subsystem's
operating system.
 • It is important to recognize that many Part II security services
depend on (embedded) AIS. These AIS should be evaluated using
Part I and Appendix A of the TNI. Encryption systems, for example,
are highly dependent upon AIS; they are addressed in Appendix
B of the TNI and Appendix C of this guideline. Appendix C presents
some considerations concerned with applying Tables 1, 2, and 3
to encryption systems.




25


TNI Environments Guideline                    TNI PartII Security
Requirements


For security services that do not depend strongly on AIS, a qualitative
evaluation approach is used. For functionality, a question and
answer format is presented in Section 5.4.3. For strength of mechanism
and assurance, the concept of a risk index is used in Sections
5.4.1 and 5.4.2.
5.2 Specification and Evaluation of Security Services



Specifying and evaluating Part II security services is quite different
from a TNI Part I evaluation even though both parts are concerned
with the same three aspects of security services or capabilities:
functionality, strength of mechanism, and assurance. For clarity
these terms are defined as follows: Functionality refers to the
objective and approach of a security service. Sirength of mechanism
refers to how well a specific approach may be expected to achieve
its objectives. Assurance refers to a basis for believing that
the functionality will be achieved.
5.3 Evaluation Ratings


 • Part II evaluations are qualitative, as compared with the
hierarchically~rdered ratings (e.g., C1, C2, ...) from the TCSEC.
The results of a Part II evaluation for offered services are generally
summarized using the terms none, minimum, fair, and good. For
some services, functionality is summarized using none or present
because gradations are not meaningful. Theterm none is used to
mean the security service fails to distinguish the strength of
mechanism. The term not offered is used when a security service
is not offered.  For example, if a certain network did not include
non-repudiation as one of its security services, that network
would be rated not offered with respect to non-repudiation. Table
4 represents the evaluation structure of PartII as a matrix. It
identifies a set of security services. It also shows the possible
evaluation ranges for each service in terms of its functionality,
strength of mechanism, and assurance.





5.4 Selecting Security Services



Part II enumerates representative security services that an organization
may choose to employ in a specific situation.  Not all security
services will be equally important for a specific environment,
nor will their relative importance be the same


TNI Environments Guideline                   TNI Part II Security
Requirements

 • Table 4
 • Evaluation Structure for Network Security Services






Network Security   Criterion          Evaluation
Service

Communications     None present
Integrity
Functionality

Authentication     None               good
Strength

Assurance          None               good

Communications     None               good
Field Integrity
Functionality

Strength                              None                good

Assurance          None               good

Non-repudiation    None               present
Functionality

Strength            Denial of         None                good
                   Service

Continuity of      None               good
Operations
Functionality

Strength                              None                good

Assurance          None               good

Protocol Based     None               good
Protection
Functionality

Strength           None               good

Assurance          None               good

Network            None               present
Management
"Functionality

Strength           None               good

Compromise         None               present
Protection Data
Confidentiality
Functionality

Strength
Sensitivity level

Assurance          None               good

Traffic Flow       None               present
Confidentiality
Functionality

Strength           Sensitivity        level

Assurance          None               good

Selective Routing  None               present
Functionality

Strength           None               good

Assurance          None               good









among different environments. Selecting security services is a
management decision, with assistance provided by this guideline.


Ordinarily, the security manager would first determine whether
a particular service is required and what functionality is needed
(if there are distinctions) through a series of questions provided
in Section 5.4.3. A separate set of questions is provided for
each service shown in Table 4.


Once the functionality has been determined, the strength of mechanism
and appropriate level of assurance must be determined. The process
is similar to the determination of Part I risk in Section 4 of
this guideline.  Since the strength of mechanism and assurance
determination do not differ for the various services, these topics
are addressed first.
5.4.1 Strength of Mechanism



Determination of strength of mechanism for each service has two
components. The inadvertent threat and the malicious threat should
be analyzed separately. In many cases, the malicious threat will
dominate the inadvertent threat; malicious users can often duplicate
the circumstances of an inadvertent threat. The required strength
of mechanism is determined using a risk index similar to that
used in PartI.


For inadvertent threats, traditional risk management techniques
are used. While some countermeasures may be the same for inadvertent
and malicious threats, others may be effective only against the
former. The security manager must determine the likelihood of
a particular threat, the dollar cost of a countermeasure, and
the residual risk if the countermeasure is put into effect. The
manager concerned with these inadvertent threats is referred to
the references on risk assessment previously cited.


For malicious threats, we consider the most sensitive information
contained on the system and the lowest clearance of user who can
gain physical access to some device in the system, including access
to wireless transmissions. Some devices in the system may be physically
protected in buildings that require a clearance for admittance.
Other devices in the system, such as long-haul transmission lines,
may have no physical protection.


Protection of the information in the network system is a combination
of physical, administrative, procedural, and technical protections.
The TNIlis concerned only with the AIS hardware, firmware, software,
and configuration management protections.  Various service or
agency regulations describe methods for implementing the other
protections.


The various devices in the system must be considered separately;
for each device,


the risk index will be based on the most sensitive information
on the network system and the minimum clearance to gain physical
access to the device. Note that this is


different from the Part I risk index calculation (where the lowest
cleared user is of concern).  For some devices in the system (e.g.,
the communications media), the clearance of individuals with physical
access may be lower than that for authorized users. For convenience,
all the necessary tables are included here. Table 5, Minimum Clearance
for Physical Access, is identical to Table 1. For each device
in the system, the lowest clearance of individuals with physical
access to that device is used. Table 6 for Maximum Data Sensitivity
is identical to Table 2.

 • Table 5
 • Minimum Clearance for Physical Access






Minimum User Clearance               Rmin



Uncleared OR Not Authorized (U)       0

Not Cleared but Authorized Access     1
to Sensitive

Unclassified Information (N)

Confidential                        2

Secret (S)                            3

Top Secret (TS) and/or current       4
Background

Investigation (BI)

TS and/or current Special            5
Background

Investigation (SBI)

One Category (IC)                     6

Multiple `Categories (MC)             7








Table 6

 • Maximum Data Sensitivity







  Maximum Sensitivity  Rating             Maximum Data
        Rating


    Ratings without    (Rmax)                Sensitivity
        (Rmax)


      Categories                          with Categoriesi,1 2


    Unclassified U        0                    N/A 3


    Not Classified but    1         N with one or more Categories
       2


Sensitive N 4


    Confidential C        2         C with one or more Cate ories
       3


       Secret (S)         3         5 with one or more Categories
       4


                                    only one Category containing
5


                                    S with two or more Categories
       5


containin S


    Top Secret (TS)      5 5        TS with one or more Categories
      6


                                  only one Category containing
5 or TS


                                   T5 with two or more Categories
       7


containin S or TS


1 Where the number of categories is large or where a highly sensitive
category is involved, a higher rat-ing might be warranted.


2 The only categories of concern are those for which some users
are not authorized access.  When counting the number of categories,
count all categories regardless of the sensitivity level associated
with the data. If a category is associated with more than one
sensitivity level, it is only counted at the highest level. Systems
in which all data are in the same category are treated as without
categories.


3 Unclassified data by definition may not contam categories.


4 Examples of N data include financial, proprietary, privacy,
and mission-sensitive data. In some situa-tions (e.g., those involving
extremely large financial sums or critical mission-sensitive data),
a higher rat-ing may be warranted. This table prescribes minimum
ratings.


5 The rating increment between the Secret and Top Secret data
sensitivity l~els is greater than the in-crement between other
adjacent levels. This difference derives from the fact that the
loss of Top Secret data causes EXCEPTIONALLY GRAVE damage to U.S.
national security, whereas the loss of Secret data causes SERIOUS
damage.


Table 7 now gives the strength of mechanism requirement based
on the risk index


calculated as


Risk Index = Rmax - Rmin

 • Table 7
 • Minimum Strength of Mechanism Requirement







Risk    Strength of

 •  None

 • 1 Minimum
 • 2 Fair






>2        Good
5.4.2 Assurance



Assurance is a very important concept in the TCSEC and TNI. This
section discusses the need for assurance and the ways in which
it may be achieved.


One salient property of trusted systems is the reliance on a TCB.
 Similarly, trusted network systems rely on an NTCB. In addition
to its other responsibilities, the NTCB prevents unauthorized
modification to objects within the network system. In particular,
the NTCB maintains the integrity of the programs which provide
security services, thus ensuring that their assurance is continued.
 The NTCB provides an execution environment that is extremely
valuable in enhancing the assurance of security services. Discretionary
and mandatory access controls can be employed to segregate unrelated
services. Thus, service implementation that is complex and error-prone
or obtained from an unevaluated supplier can be prevented from
degrading the assurance of other services implemented in the same
device. Furthermore, an NTcB ensures that the basic protection
of the security and integrity information entrusted to the network
is not diluted by various supporting security services.


The relationship of the risk index to the required assurance is
expressed in Table 8.


TNI Environments Guideline                    TNI PartII Security
Requirements


Table 8


Minimum Assurance Requirements


Risk       Part II


       Index   Assurance Rating

 •  None

 • 1 Minimum
 • 2 Fair
 • >2          Good









Assurance of the design and implementation of PartII mechanisms
is also related to the assurance requirements in Part I because
service integrity depends on protection by the NTCB or TCBs. Table
9 expresses this dependency.  The second column identifies the
minimum Part I evaluation which supports the Part II assurance
requirement. Note that Table 9 is applicable only to those PartII
services not strongly dependent on AIS; the AIS implementing those
services can be directly evaluated under PartI and Appendix A
of the TNI.


Note that the Evaluation Class calculation in Part I will not
necessarily be the same as the Minimum Part I Evaluation in Table
9. This is because the Rmin for Part II may be different from
that of Part I since the Part II protections are oriented towards
outsiders (those with physical access) rather than towards users.
Depending on the particular environment, either the Part I requirement
or the Part II requirement may dominate. The latter would be the
case if a system were operated in the system high mode-where all
users were cleared to see the most sensitive information-but the
network was exposed to lower clearance individuals.
5.4.3 Functionality



This section asks questions about each of the security servi'ces
contained in PartII  of the TNI. These questions are designed
to help the security manager identify the functionality required
for each security service. The questions should be answered in
sequence, unless the answer to one question contains an instruction
to skip ahead.


Authentication

 • 1. Is there a requirement to determine what individual, process
or device is at the other end of a network communication? If yes,
document this requirement.






 • Table 9
 • Part II Assurance Rating






PartII                                Minimum PartI

Assurance Rating                     Evaluation

Minimum                              CI

Fair                                 C2

Good                                 B2









If no, skip to Communications Field Integrity.

 • 2. Do you have a requirement to identify and authenticate
the specific hardware device at the distant end-point involved
in the network communication?  If yes, then you have a functionality
requirement for authentication.  This functionality may be implemented
at one or more protocol layer. For example, a specific control
character, ENQ (enquiry or who-are-you) may be used to return
immediately a stored terminal identifier.
 • 3. Do you have a requirement to identify and authenticate
the location of the hardware at the distant end-point or in any
intermediate system involved in the network communication?
 • If yes, then you have a functionality requirement for authentication
at protocol layer 2, the Link Layer or layer 3, the Network Layer.
 • 4. Do you have a requirement to identify and authenticate
the specific operating system or control program at the distant
end-point or in any intermediate system involved in the network
communication?
 • If yes, then you have a functionality requirement for authentication
at protocol layer 4, the Transport Layer.
 • 5. Do you have a requirement to  identify and authenticate
the  subject (process/domain pair) at the distant end-point involved
in the network communication?
 • If yes, then you have a functionality requirement for authentication
at protocol layer 4 or above.






 • 6. Do you have a requirement to identify ad authenticate the
application or user at the distant end-point involved in the network
communication?  If yes, then you have a functionality requirement
for authentication above protocol layer 7, the Applications Layer.
The Applications Layer provides an interface to the application.
Authentication information may pass over this interface.  Authentication
of a user is addressed in Part I of the TNI.  Application process
authentication is outside the scope of the 05I Security Architecture,
but does fall within the scope of TNI PartII Security Services.
 Have you chosen to use some mechanism other than encryption to
provide authentication? If so, your strength of mechanism is shown
in Table 7.  If your authentication mechanism is encryption based,
see the appropriate encryption authority (e.g., NSA). Even if
encryption is used, some supporting processes may need to satisfy
the strength of mechanism shown in Table 7 (depending on the architecture).
 For example, a database that relates encryption keys to specific
users may need to be trusted.







Communications Field Integrity

 • 1. Do you have a requirement to protect communication against
unauthorized modification?  If no, skip to Non-Repudiation.
 • 2. Are your protection requirements the same for all parts
of the information communicated?
 • If no, then you should identify the separate parts and answer
the rest of the questions in this section separately for each
part. Each part is known as a field.
 • There are two major fields: protocol-information, whherein
the network is informed of the destination of the information
and any special services required; and user-rlata. Not every protocol
data unit (PDU) contains user-data, but protocol-information is
necessary.  Each of these fields may be divided into additional
fields; depending on your application, protection requirements
for fields may differ.






 • 3. Do you have a requirement for detecting unauthorized modification
to part or allofaPDU?
 • If yes, you have a requirement for at least minimum functionality.
 • 4. Do you have a requirement for detecting any of the following
forms of message stream modification: insertion, deletion, or
replay?
 • If yes, you have a requirement for at least fair functionality.
In addition, your functionality must be incorporated in a connection
oriented protocol.
 • 5. Do you require that, if message stream modification is
detected, recovery (correction) should be attempted?
 • If yes, you have a requirement for good functionality. In
addition, you must implement integrity in a reliable transport
(layer 4) mechanism.




Non-repudiation

 • 1. Do you have a requirement to be able to prove (to a third
party) that a specific message transfer actually occurred?  If
no, skip to Denial of Service.
 • 2. Do you have a requirement for proving that a specific message
was sent?
 • Specific message means that the identity of the subject sending
the message, the host computer and/or mail agent/server, time
and date, and contents are all uniquely and unalterably identified.
 • If yes, then you have a functionality requirement for non-repudiation
with proof of origin.
 • 3. Do you have a requirement for proving that a specific message
was received?
 • Specific message means that the identity of the subject to
which the message was delivered, the host computer and/or mail
agent/server, time and date, and contents are all uniquely and
unalterably identified.
 • If yes, then you have a functionality requirement for non-repudiation
with proof of delivery.







Denial of Service

 • 1. Do you have a requirement to assure the availability of
communications service or to determine when a Denial of Service
(DOS) condition exists? A DOS condition is defined to exist whenever
throughput falls below a pre~stablished threshold, or when access
to a remote entity is unavailable, or when resources are not available
to users on an equitable basis. For a DOS condition to occur,
the user must have priority to access the system or resources.
 If no, skip to Data Confidentiality.
 • 2. Do you have a requirement to detect conditions that would
degrade service below a pre-selected minimum and to report such
degradation to the network operators?
 • If yes, you have a requirement for at least minimum denial
of service functionality.
 • 3. Could failure of the system to operate for several minutes
lead to personal injury or large financial loss?
 • If yes, you have a requirement for at least fair denial of
service functionality.
 • 4. Do you have a requirement for service resiliency that would
continue-perhaps in a degraded or prioritized mode-in the event
of equipment failure and/or unauthorized actions?
 • If yes, you have a requirement for at least fair denial of
service functionality.
 • 5. Could failure of your system to operate for several minutes
lead to loss of life?
 • If yes, you have a requirement for good denial of service
functionality.
 • 6. Do you have a requirement for automatic adaptation upon
detection of a denial~fservice condition?
 • If yes, you have a requirement for good denial of service
functionality.







Protocol Based DOS Protection

 • 1. Do you want advanced knowledge of unavailability of service?

 • If no, skip to Network Management.
 • If yes, do you want to implement alternatives?






If yes, you should employ this alternative basis and skip to Network
Management.

 • 2. In general, ordinary protocol mechanisms don't provide
protection against malicious attacks or bizarre errors. Do you
have a requirement to detect a DOS condition which cannot be met
by the protocols used as part of normal communications?
 • If no, you do not have a functional requirement for protocol-based
DOS protection and should skip to Network Management.
 • 3. The TNI suggests the following protocol-based mechanisms:

 • a. Measure the transmission rate between peer entities under
conditions of input queuing, and compare the measured transmission
rate with a rate previously identified as the minimum acceptable;
 • b. Employ a request-response polling mechanism, such as "are-you-there"
and "here-I-am" messages, to verify that an open path
exists between peer entities.






If you have identified any additional mechanisms, include them
in your list of required mechanisms.


Network Management

 • 1. Do you have a requirement for (at least) detecting a denial
of service condition that affects more than a single instance
of communication  or attempted communication?
 • If no, skip to Data Confidentiality.
 • If yes, you have a functional requirement for network management
denial of service protection.







Data Confidentiality

 • 1. Do you have a requirement to protect any part of transmitted
data from disclosure to unauthorized persons?  If no, skip to
Traffic Flow Confidentiality.
 • 2. Is your requirement for confidentiality limited to selected
field of user~ata within a PDU?
 • If no, then you require confidentiality for the entire data
portion of each PDU.
 • Continue with Traffic Flow Confidentiality.
 • 3. Is there a reason to encrypt only selected fields (e.g.,
cost savings, legal requirements)?
 • If yes, you require selected field confidentiality.  If no,
you require full confidentiality on the data portion of each PDU.




Traffic Flow Confidentiality

 • 1. Do you have a requirement to prevent analysis of message
length, frequency, ad protocol components (such as addresses)
to prevent information disclosure through inference (traffic analysis)?
 • If no, skip to Selective Routing.
 • If yes, you have a functional requirement for traffic flow
confidentiality.




Selective Routing

 • 1. Do you have a requirement to choose or avoid specific networks,
links, relays, or other devices for any reason at any time?
 • If yes, you have a functional requirement for selective routing.





6 Interconnecting AIS



The definition of Interconnected Accredited AIS recognizes that
parts of a network may be independently created, managed, and
accredited.  AIS in different security domains 13 generally operate
under different security policies, consequently, it is difficult
to combine them into a Unified Network. For example, AIS operated
by the U.S. DOD and NATO cannot be combined into a Unified Network,
since they enforce different policies and do not have a common
authority.


Interconnecting systems that support different security domains
(e.g., classified, sensitive unclassified) adds additional complexity.
 Exchange of information among these different security domains
requires identification of the markings and protection given to
information when transmitted to another domain.  For example,
several evolving approaches to the protection of sensitive unclassified
information [17] consider "that sensitive information is
not part of the same hierarchy as classified information".


There are technical criteria for judging the trustworthiness of
Interconnected Accredited AIS: an Interconnection Rule, which
ensures that information conveyed between subsystems is labeled
properly, and risk factors such as propagation of local risk and
the cascading problem. These criteria are examined in some detail
below.
6.1 Agreement Between Accreditors



Interconnection of AIS between security domains requires a documented
agreement identifying the interconnection requirements and all
safeguards.  This agreement will have many similarities to the
MOA discussed in Section 3.2. It will probably have to reconcile
different security policies and philosophies of protection, identifying
the conditions under which specified classes of information can
be exchanged among domains. In addition to the information included
in> the MOA, this agreement between managers of different security
domains should address the mappings of policy and countermeasures
between the domains.  In many ways this agreement takes on the
character of an NSAD for the agreed upon information exchange
between domains.


________________________


13 A security domain is a collection of A[$ under the control
of a single administrator that en-forces or operates under a specified
policy. There can be sub-domains, (e.g., Army and Air Force are
sub-domains under the Department of Defense.)
6.1.1 Accreditation Range



An accreditation designates a system's mode of operation and range
of data sensitivity' levels. The accreditation range reflects
the Accreditor's judgment on the subsystem's ability to exchange
information within an acceptable level of risk, with respect to
its network connections, and in accord with the designated sensitivity
levels.


The range must be a single level in the case of a system high
or dedicated device14.


If the accreditation range comprises more than a single level,
the system is trusted to reliably segregate data by level within
its accreditation range, and label it accurately for transmission
over multilevel interfaces. The accreditation range will be specified
in the MOA. The accreditation range is used in determining whether
communication between systems is permitted.

 • Figure 1
 • Information Levels and Accreditation Ranges





TS



                S-C
S



C


                C2             Evaluation Class
 B3


                S             Accreditation Range
TS-C


                SH             Operating Mode
MLS


As shown in Figure 1, an AIS may contain information at levels
that are below its accreditation range.  For example, a C2 host
which contsuns Secret (S) and Confidential  information,
is not trusted to segregate this confidential and Secret information.
Therefore, it is accredited to operate in system high (SH) mode
at Secret (the highest sensitivity level of information on the
system), and its accreditation range is the single level Secret.
All exported information must be labeled with the system high
sensitivity label until there is a manual review to assign the
information a lower 14 Often in the discussion it is not appropriate
to distinguish between a component and a sub-system; in that case
we use the term device.


classification level. In contrast, a B3 multilevel secure (MLS)
host, which contains Top Secret (TS), Secret, and Confidential
information could be assigned an accreditation range equal to
the entire set of levels processed. In this case, the label of
the exported data is equal to the actual level of the exported
data, unless unclassified data is to be exported.


Figure 2 illustrates the accreditation ranges of two interconnected
subsystems.


Although Subsystem Y is able to separate its three levels of information,
it may exchange information with Subsystem X only at the S and
C levels.

 • Figure 2
 • Accreditation Ranges of Two Interconnected Sub systems







Subsystem X                                      Subsystem
Y
TS



     S -------------------------------     S


     C -------------------------------            C


   Class B1           Class B3


In a network, an accreditation range bounds the sensitivity levels
of information that may be sent (exported) to or received (imported)
from each interconnected subsystem15. For example, if a network
consists of only dedicated and system high subsystems, each subsystem
will be assigned single-valued accreditation ranges (i.e., an
accreditation range consisting of one sensitivity level).


When the same communications channel processes information at;different
levels, the data must be labeled through some protocol agreed
upon by the communicating systems.


______________


15 Note that information exported or imported to a subsystem having
a single-level accredita-tion range is implicillylabeled at that
level. It is also possible for a subsystem with a mul-tilevel
accreditation range to employ network interface devices with single-level
ports, in which case the data transferred over such ports is also
implicitly labeled.


DODD 5200.28 Enclosure (5) also addresses AI5 that have not been
accredited:


Untrusted, unaccredited AIS ... may be components of a network....
Only unclassified information, which does not include sensitive
unclassified information, may be sent to ad from untrvsted, unaccredited
AIS.


This trvst requirement is satisfied by restricting the accreditation
rage of the untrusted, unaccredited AIS to Unclassified (U).
6.1.2 Device Range



A network subsystem is typically connected to another subsystem
through some kind of 1/0 network interface or device (see Figures
3~) ad the same device may provide connection to multiple subsystems.


Although a 1/0 device is part of a subsystem, it may be designated
to process a more restricted set of sensitivity levels than the
accreditation rage of the subsystem as a whole. This leads to
the concept of a device range. Each 1/0 device in a subsystem
that is used to communicate with other subsystems in the network
must have a device rage. The device rage may be single level,
or it may be a set of levels (in which case the device is referred
to as multilevel), and it must be included within the subsystem
accreditation range. The TCSEC states that "systems that
have been evaluated at classes B2 ad above must support minimum
ad maximum security labels for all multilevel 1/0 devices".
The purpose of device labels is to document the constraints placed
on the security levels of information authorized for the devices.


Each physically attached multilevel system (if any) has a minimum
ad maximum sensitivity level associated with it. A B1 or higher
system interconnected to a second system must ensure that both
imported and exported information is contained within appropriate
sensitivity levels.
6.1.3 Information Transfer Restrictions



The following points summarize the discussion on the restrictions
imposed on information transfer between interconnected devices.


Information exported or imported using a single-level device is
labeled implicitly by the security level of the device. As shown
in Figure 3, any information transferred between the single-level
(S) devices on Subsystems X and Y is implicitly labeled S.

 • Figure 3
 • Implicit Labeling







Subsystem X                            Subsystem Y


Information exported from one multilevel device and imported at
another multilevel device must be labeled through an agreed-upon
protocol, unless it is labeled implicitly by using a communications
link that always carries a single level.  For instance, in Figure
4, Secret and Confidential information may be transferred between
the multilevel devices.

 • Figure 4
 • Protocol Labeling







Subsystem X                           Subsystem Y

 • Figure5
 • Compatibility Labeling







Subsystem X                            Subsystem Y


Information exported at a given security level can be sent only
to a importing device whose device rage contains that level or
a higher level. In Figure 5, Subsystem X is allowed to export
only Secret information to Subsystem Y's multilevel device.  Subsystem
Y is allowed to export Secret ad Confidential information to Subsystem
X, because the device rage Subsystem X is TS-S.  If the importing
device rage dominates the exported level, the information is implicitly
or explicitly relabeled upon receipt at a higher level within
the importing device range.

 • Figure 6
 • Relabeling







Subsystem X                            Subsystem Y


In Figure 6, Subsystem Y relabels information imported from Subsystem
X. The information transfer restrictions also permit one-way communication
(i.e., no acknowledgments) from one device to aother whose rages
have no level in common, as long as each level in the sending
device rage is dominated by some level in the receiving device
rage. It is never permitted to send information at a given level
to a device whose rage does not contain a dominating level.


In most interconnected subsystems, the bidirectional flow of information
is permitted. In this environment, the sensitivity level of any
transmitted message must be within the accreditation range of
both the sending and receiving systems.  In some networks,  an
additional restriction on information flow may be unidirectional
communications. This restriction may enhance security.  The following
discussions refer to Figure 7.

 • Figure 7
 • Bidirectional and Unidirectional Information Flow







        Subsystem X
Subsystem Y


              TS                     (C or U)
      C
U



          SH (TS)                 Subsystem Z
   MLS (C-U)


                                      TS


                                       S


                                       C


                                   MLS (TS-C)


The system high mode is usually assigned to AIS that are unevaluated
or are NCSC~valuated in class C. These AIS do not employ explicit
labels because they cannot be trusted to differentiate between
sensitivity levels. All information within these AIS is implicitly
labeled. When exported on a single level channel, by default the
information is labeled implicitly by the level of the channel.
Human-readable output must be labeled at the system high level;
it may be manually downgraded by an authorized reviewer.


Explicit labels are required on a multilevel channel. In order
to export explicit labels, Subsystem X would normally be expected
to be NCSC-evaluated at BI or above, or employ an 1/0 device,
such as those shown in Figure 6, NCSC~valuated at BI or above.
Also, Subsystem X or the 1/0 device should be used as specified
in Section 4 of this guideline. Lacking such NCSC~valuation, the
MOA between the Accreditors would have to specifically address
these labels.


Subsystem X can import a message from Subsystem Y, but cannot
acknowledge receipt of that message, because an exported acknowledgment
(labeled TS) cannot be imported by Subsystem Y, which can only
receive C or U information. Transmitting an acknowledgment from
Subsystem X to Subsystem Y would constitute a write-down (i.e.,
writing information at a lower sensitivity level-generally a security
violation.)


Subsystems Y and Z can exchange information at C since this level
is in the accreditation range of each subsystem. When only unidirectional
communication (no acknowledgment) is utilized between two subsystems,
write up is permitted if each sensitivity level in the source
subsystem is dominated by a sensitivity level in the destination
subsystem. The receiving subsystem must change the sensitivity
level of the message when the message is received. For instance,
U information sent from Subsystem Y will be labeled C by Subsystem
Z.
6.2 Interconnection Rule



The Interconnection Rule states that each device in the network
must be separately accredited to operate in an approved security
mode of operation and with a specific accreditation range. The
device is accredited to participate in the network at those levels
and only those levels. This means that information exported at
a given sensitivity level can be sent only to an importing device
whose accreditation range contains that level or a higher level.
Information is relabeled, implicitly or explicitly, upon reception
at a higher level within the importing device accreditation range
only if the original level is not in that range.


According to the Interconnection Rule, a multilevel network may
contain devices with different operating modes: dedicated, system
high, partitioned, and multilevel.  Also the devices may differ
in the sensitivity levels and categories which they process, and
the formal access approvals of their users (some users may not
have access to all information).


Figure 7 illustrates the flexibility of the Interconnection Rule.
For example, the interconnection Rule will allow, with certain
restrictions, a multilevel subsystem to communicate with a single-level
subsystem and with another multilevel subsystem (and


the two MLS subsystems may have different accreditation ranges).
It also allows for one-way communication to a higher-level system.
It is intended to be a non-restricting rule and yet ensure that
each system receives only information that it can properly mark
and handle. Interconnection in the context of the Interconnection
Rule means only direct connections, that is, without any intermediate
accredited subsystem.


The Interconnection Rule alone does not guarantee that classified
information will not be exposed to greater risks in a network
than in a stand-alone environment. One problem in networks that
is dealt with at some length below is the cascading problem.

 • Figure 8
 • A Complex Interconnection







Subsystem X              Subsystem Y
6.2.1 A Complex Example



The Interconnection Rule and device range allow for some rather
challenging situations. Consider, for example, the connection
depicted in Figure 8. The system on the left processes TS information
of two types: categories A and P (where P is the union of categories
C and D, P = C U D). The system on the right processes the categories
C and Q (where Q is the union of categories A and B, Q = A U B).
The two devices have no sensitivity levels in common. Yet this
is a legitimate connection as long as only TS ,A and TS ,C information
is transferred.  Any information sent must be relabeled upon receipt.
Information in category A is relabeled Q when received on the
right, ad information in category C is relabeled P when received
on the left 6.3 Risk Factors


There are two global considerations that affect the interconnection
of systems.


The first is called propagation of local risk and the second is
the cascading problem.  Before discussing these considerations,
the concepts of subsystem connection view and global network view
need to be introduced.


As discussed in the previous section, any subsystem that is connected
to other subsystems must enforce the Interconnection Rule. Using
the subsystem connection


view, each subsystem responsible for maintaining the separation
of multiple levels of information must decide locally whether
or not information can be sent or received.  This view, then,
does not require a subsystem to know the accreditation ranges
of all other subsystems on the network; only of those with which
it can communicate without an intermediary.


The Interconnection Rule applies to communication between any
two (or more) accredited systems. However, even when the Interconnection
Rule is followed, there may be other potential security problems
that will require the implementation of additional constraints
on the network. In order to address these problems, it is necessary
to adopt a global view of the network. This view requires a knowledge
of the accreditation ranges of all the subsystems in the network.
That is, it is no longer determinable locally whether or not a
constraint is being satisfied. These accreditation ranges are
taken into account when determining whether or not a subsystem
should be allowed to connect to the network. In this way, the
potential damage that can occur when information is compromised
or modified can be limited to an acceptable level.


Two global concerns are discussed below. One concern is the propagation
of local risk; the other is the cascading problem.
6.3.1 Propagation of Local Risk



The term Propagation of Local Risk comes from the notion of jeopardizing
the security of a system as a result of weaknesses in other systems
to which it may be connected. Table 3 in Section 4 recommends
minimum classes of trusted systems for specific environments.
Unfortunately, in many cases, operational needs have led to the
accreditation of systems for multilevel operation that would not
meet the requirements of the recommended class. While this increased
risk may be accepted by the Accreditor of a particular system,
connection of such a system to a network exposes users of all
other subsystems in the network to the additional risk. Consequently,
when an unevaluated system, or one that does not meet the class
recommended for its accreditation, is proposed for connection
to a network, constraints should be considered,  such  as  one-way
 connections,  manual  review  of  transmissions, cryptographic
isolation, or other measures to limit the risk it introduces.


In the special case of a common user network such as DDN, it may
be necessary to provide communications capabilities among systems
that do not conform to the security requirements established by
the network Accreditor (i.e., a system meeting no security requirements
may be connected to a network.) One common way to provide network
service to these non~onforming systems while still protecting
the other, conforming, systems would be to segregate the non-conforming
systems into closed communities that could not directly communicate
with conforming systems.  This approach is discussed in detail
in the Defense Data Network Security Architecture [18].
6.3.2 The Cascading Problem



One of the problems that the Interconnection Rule does not address
is the cascading problem, discussed in Appendix C of the INI.
The cascading problem exists when an attacker can take advantage
of network connections to reduce the nominal system resistance
against leaking information across a range of sensitivity levels.
Most multilevel systems, evaluated or not, are vulnerable to some
risk that information can be leaked from a higher to a lower level
supported on the system. The accreditation range of a subsystem
represents a judgment that the risk is acceptable for that range
of classifications.  The size of the range is one indication of
the attractiveness of the system as a target, so larger ranges
call for more care in system design and management. In particular,
Section 4 of this guideline discusses computation of a risk index
calculation based on the accreditation range, and recommends a
minimum evaluation class for a given risk index.


The cascading problem results from the observation that subsystems
may be connected in such a way that the network covers a larger
sensitivity level range than the individual systems are accredited
to handle. Depending on the actual topology of the interconnection
and the characteristics of the installations, the arnount of effort
required for an attacker to take advantage of residual vnlnerabilities
may be less than what is required for the network sensitivity
range.


To see how this is possible, consider two systems, each of which
is accredited to handle two adjacent classifications of information,
as shown in Figure 9. Subsystem A processes Secret and Top Secret
information, and all users are cleared to at least the Secret
level. Subsystem B processes Confidential and Secret information,
and all users are cleared to at least the Confidential level.


The network as a whole has three levels of information. However,
the leakage resistance of the network is only that offered by
two systems qualified for only two levels. To make Top Secret
information available to Confidential users, an attacker might
attempt to:

 • 1. Install a Trojan horse in Subsystem A to leak some Top
Secret information to Secret
 • 2. Send that information across the network link to Subsystem
B
 • 3. Install a Trojan horse in Subsystem B to leak the original
Top Secret information, now labeled Secret, to Confidential.




The path from Top Secret in Subsystem A to Confidential in Subsystem
B is referred to as a cascading path, with three steps. Step 1
is from TS to S in Subsystem A, Step 2 is the network link, and
Step 3 is from S to C in Subsystem B. Steps (1) and (3), the downgrading
steps, offer resistance commensurate with strictly smaller ranges.
 Step (2), the network link, offers no additional resistance,
given that the two Trojan horses have been written and installed.

 • Figure 9
 • Cascading Problem





Subsystem A



                      TS                          Subsystem
B


                       S                              S


                                                      C


The question is, whether subverting two systems qualified for
two levels of information is as hard as defeating one system qualified
for three levels of information.  In some cases it might be.
Lee [19] gives an argument that if two systems have probabilistically
independent flaw sources, "...the resistance to threat of
a cascade of two B2 systems is approximately the same as, or even
better than, that of a B3 system."


But Lee also remarks that demonstrating effective independence
of flaw sources m a practical case is not easy, and that two systems
may have the same or equivalent flaws, particularly if their TCBs
are the same, or are separate implementations of a single flawed
design. Exploitation of the flaws on two or more systems does
present additional resistance to the attacker, but it should be
kept in mind that physical access to all interconnected systems
is not necessary to send untrusted software to them, as our experience
with viruses shows unmistakably.
6.3.2.1 Tests for Cascading.



For a relatively large and complex interconnection of systems,
it might not be obvious whether a cascading problem exists. Appendix
C of the TNI includes three approaches, with different degrees
of complexity and precision, for recognizing a potential cascading
problem. These range from a simple test that is rather pessimistic,
called the nesting condition, to a complex procedure. Appendix
A of this TNIEG reviews the nesting condition, and presents additional
information concerning tests for the cascading problem.

 • Whichever test for cascading is employed, its result is to
focus attention on certain subsystems and their network connections
that might potentially be subject to a cascading threat.  The
next step is to determine whether the systems involved are actually
vulnerable to the multiple coordinated attack that is necessary
for cascading, ad, if so, to consider countermeasures.


6.3.2.2 Solutions.


 • There are several ways to tackle a cascading problem. Since
cascading depends on cooperative action by malicious software
on the participating subsystems, one approach is to institute
configuration controls to prevent installation of unscrvtinized
software, or perhaps isolating it from network usage.
 • Another solution is to use a more trusted subsystem at appropriate
nodes in the network, so that an attacker will be forced to overcome
a protection mechanism commensurate with the seriousness of the
potential compromise. In Figure 9, for example, if either subsystem
A or subsystem B is NCSC-evaluated at class B3, which is sufficient
according to Table 3 in Section 4 of this guideline for a rangd
of Top Secret to Confidential, then the attacker is presented
with an acceptable level of difficulty.




A cascading threat can also be interdicted by eliminating certain
network connections, to break paths by which an attacker could
compromise information with insufficient resistance. This solution
is practical only when the links to be eliminated are not needed
for operational reasons. Sometimes end-to-end encryption can be
used to address a cascading threat while preserving necessary
connectivity, by reducing the level of information available to
intermediate systems on a communication path.
APPENDIX A

Tests for the Cascading Problem



The cascading problem was discussed in Section 6. This appendix
reviews the approaches presented in Appendix C of the TNI for
testing whether a cascading problem exists in an interconnection
of accredited subsystems. Three criteria are given there: the
nesting condition, the cascade condition, and a heuristic procedure.
The nesting condition is a simple but pessimistic test that can,
in some cases, dismiss the possibility of a cascading problem.
When it fails, there is not necessarily a cascading problem; other,
more accurate, tests should then be applied to confirm and locate
it.  This appendix first summarizes the nesting condition, and
then discusses other approaches  briefly.  A  forthcoming  report
 will  provide  further  guidance  on computational approaches
for the cascading problem.
A.l Nesting Condition



The nesting condition is evaluated solely on the basis of the
accreditation ranges of the subsystems. In the form given both
here and in the TNI, it is applicable only when all sensitivity
levels are totally ordered - that is, if they can be placed in
order such that each one is higher than the one before it. This
is true, in particular, if they are pure classifications, with
no categories or compartments.


The nesting condition is satisfied, by definition, if the accreditation
ranges of each pair of subsystems are either disjoint or nested.
A pair of accreditation ranges is disjoint if they have no levels
in common. They are nested if one range is included (as a subset)
in the other. All possible pairs (not just those of adjacent subsystems)
must be considered, but some pairs may be nested while others
are disjoint.


If the nesting condition is satisfied, there is no cascading problem.
Because the nesting condition does not take into account which
network subsystems are actually connected to one another, it can
sometimes give a pessimistic result, i.e., there are cases when
the nesting condition fails, but there is actually no cascading
problem.

 • Figure A-I
 • Accreditation Ranges of Two Interconnected Sub systems





Subsystem Y

Class B1



Example 1:  Consider the situation illustrated in Figure A-I.
The accreditation range of Subsystem X is nested within that of
Subsystem Y (i.e., C-S is completely contained within C-TS). Therefore,
the nesting condition is satisfied, and there is no cascading
problem.

 • Figure A-2
 • Cascading Problem





Subsystem A



                      TS                          Subsystem
B


                       S                              S


                                                      C


Example 2: Consider the situation illustrated in Figure A-2. The
accreditation ranges of Subsystem A and Subsystem B are not disjoint;
neither is one completely contained within the other. Therefore,
the nesting condition fails, ad a cascading problem is possible.
Note, however, that the nesting condition would still fail even
if the two subsystems were not connected to one another, yet in
that case there would be no cascading problem.


The situation is more complex when sensitivity levels are drawn
from a partially ordered set, so that the accreditation ranges
of some subsystems have sensitivity levels that are incomparable.
Two sensitivity levels are incomparable when neither is greater
than or equal to the other.  Sensitivity levels with category
sets are, in general, incomparable. An extended form of the nesting
condition has been devised that applies to partially ordered sensitivity
level sets . [20] A.2  Other Approaches Appendix C of the TNI
contains two other criteria for the cascading problem: the cascade
condition, which is a mathematical characterization of the problem,
and a heuristic procedure. These criteria have been superseded
by improved methods since the publication of the TNI. The new
approach is described in a separate report, in order to give adequate
scope to the presentation of background and context necessary
to apply it appropriately.


The need for a new approach arose from a recognition of the limitations
of the existing criteria.  The cascade condition is accurate but
it is not, in itself, a computational procedure. It is limited
by its assumption that all of the interconnected subsystems have
been given evaluation classes. The heuristic procedure is believed
to provide a conservative approximate test for cascading, but
only when applied to interconnections in which all communication
paths are two-way, i.e., capable of both sending and receiving.
A simpler procedure is now available.
APPENDIX B

Background References



Neither the TNI nor this TNIEG contain tutorial information on
security and networking; it is assumed that the reader will have
some background in both areas.  There is considerable literature
available. Following are some references that provide background
and related information concerning security in networks:

 • 1 M. D. Abrams and H. J. Podell, Computer and Network Security,
a Tutorial, IEEE Computer Society Press 1987.
 • 2 D. W. Davies and W. L. Price, Security for Computer Networks,
John Wiley & Sons 1984.
 • 3 D. E. Denning, Cryptography and Data Security, Addison-Wesley
1983.
 • 4 M. Gasser, Building a Secure Computer System, Van Nostrand
Reinhold Company 1988.
 • 5 International Standards Organization, Information Processing
Systems - Open System Interconnection - Basic Reference Model,
15 October 1984. International Standard 7498.
 • Part 2: Security Architecture, February 1989.1507498-2-1988(E).
 • 6 Charles P. Pfleeger, Security in Computing, Prentice-Hall
1989.
 • 7 Andrew S. Tanenbaurn, Computer Networks, Second Edition,
Prentice-Hall 1988.





APPENDIX C

Encryption



May networks today use or plan to use encryption as a fundamental
mechanism for providing security services. The encryption devices
provide a security perimeter at the protocol layer at which they
provide service (typically the Network or Transport Layer). This
section presents some information on how an encryption system
can be part of the NSAD. It discusses MAC and DAC, use of encryption
to reduce the number of AIS, and the risk index of the encryption
system.
C.1 Use of Encryption



As indicated in the TNI, an encryption mechanism is evaluated
differently than other mechanisms. Evaluating encryption mechanisms
has a long history predating the TNI.  Evaluation of an encryption
mechanism is part of COMSEC.  Generally, encryption mechanisms
receive a rating of the highest level of classified information
which may be protected using that mechanism. Therefore, the only
rating applicable to an encryption mechanism is the classification
level of the information that is to be protected. This classification
level also establishes the requirement.


In general, organizations using the TNI and this document select
their encryption mechanisms from a list provided by an organization
which is responsible for evaluating such mechanisms. In many cases,
that organization is the NSA.


A more complicated situation exists when encryption is employed
above the Link Protocol Layer, layer 2. At layers 3 and 4 the
protocols are concerned with the end systems or intermediate devices
(e.g., hosts, network switches) that the links connect.  Higher
layers are concerned with other peer entities. Traditionally,
encryption applied above layer 2 has been termed end-to-end encryption,
or E3.


An E3 system may be provided as (part of) an NTCB. When the E3
system is integral to the NTCB, the use of the E3 system requires
evaluation under the TCSEC with interpretations in the TNI. The
evaluation must consider (1) the accreditation rage of the user
interface, (2) the risk index for the bypass in the E3 device,
and (3) the risk index between the highest sensitivity data ad
the lowest clearance of user on the network.


Depending on the design, devices of an E3system may satisfy all
requirements for a system evaluated under PartI of the TNI. MAC
may be provided either explicitly or implicitly. Explicit MAC
is provided if the packets sent by the encryption device include
a security label. Implicit MAC is provided if the security level
must be inferred from the encryption key used to protect the data.
All data protected by that key must be classified at a single
security level.


DAC is often provided in an E3 system as well. Typically, keys
for exchanging data are provided to the E3 devices only after
DAC has been applied. The encryption devices can provide identification
ad authentication. While identification is generally done explicitly
(by transmitting an identifier), authentication can be done implicitly
(i.e., by the use of a unique key). The encryption devices may
perform certain types of auditing as well. Typically, a device
collects information and forwards it to another device for storage.
 Information collected may include: connections established, connections
refused, packets with inappropriate labels, ad misrouted packets.
The granularity provided by these E3 mechanisms is determined
by the protocol layer at which the service is offered.

 • Figure C-1
 • Typical Interconnected AIS







AIS 1       AIS 2       AIS 3     AIS 4      AIS 5      AIS 6
      AIS 7


In a typical network there will be a number of AIS. For example,
two hosts are often attached to separate local networks connected
by a wide area network (WAN).  As shown in Figure C-1, the path
between the hosts (without E3) may involve 7 separate interconnected
AIS.


TNI Environments Guideline
      Encryption


E3 can help reduce the number of AIS. By placing E3 devices between
each host and the LAN to which it is connected ad incorporating
suitable key distribution components, the LANs and WAN collapse
into a single network system and the path now traverses only three
AIS, as shown in Figure C-2.  AIS 2 provides security services
to the hosts, therefore, it may be part of the NTCB.

 • Figure C-2
 • Using End-to-End Encryption to Reduce Number of AIS







AIS1                               AIS 2
      AIS 3


There may be a hierarchy of trusted system views. For example,
E3 may be provided at protocol layers 3,4, and 7. Depending on
the architecture, the layers of E3 could constitute a single NTCB
or each could be a separate NTCB. In the latter case, the devices
supporting different layers would be part of different AIS and
the interconnection rules would be applied between higher and
lower protocol layers.


In general, an AIS at a higher protocol layer encompasses more
devices than one at a lower protocol layer. The granularity of
services offered is also finer at the higher protocol layer.


In a situation where the higher protocol layer encryption system
also has a higher evaluation class, the lower protocol layers
might be considered less trusted just as current E3 designs treat
the subnetwork as untrusted. Continuing the analogy, just as certain
physical security requirements are imposed on the untrusted suLbnetwork,
the higher protocol layer encryption might rely on characteristics
of the lower protocol layers.


However, one may be faced with a dilemma that the higherprotocollayer
E3 system has a lower security evaluation than the lower-protocol-layer
trusted system.


For example, a WAN with E3 at layer 3 might be evaluated Al. The
system might also provide E3 at layer 4, but an NTCB that includes
layer 4 might. only be rated B2. In this case, treating the subsystems
constituting the separate layers as separate AIS and using the
Interconnection Rule to accredit the network as a whole could
prove advantageous, as illustrated in Figure C-3.

 • Figure C-3
 • Separate Layers Treated as Separate AIS







                        B2   B2


        (N-C)                (N-C)
0SI Layer 3 Network



   B2   B2


                      (S-TS)                    (S-TS)
C.2 Encryption Mechanisms



In a trvsted AIS, the recommended evaluation class is determined
using a risk index based on the highest data classification and
the lowest user clearance. In considering an E3 subsystem in a
network, three separate indexes must be considered [21]:

 • 1. The subscriber's range of sensitivity levels.  The cleartext
side of the encryption subsystem must be sufficiently trusted
to maintain separation among the cleartext data streams sent and
received by the subscriber attached to the encryption subsystem.
A risk index is based on the highest and lowest sensitivity levels
sent or received by the subscriber through this encryption subsystem.







2. The bypass. In an E3 system, protocol control information must
be sent around the encryption unit through a bypass. The software
and hardware to mimplement the bypass must be trusted not to send
user data through the bypass. A risk index can be computed based
on the difference between the sensitivity level of the cleartext
information and the sensitivity level of the untrusted subsystems
of the network.

 • 3. The range of sensitivity levels across the network. This
risk index is concerned with the difference between the highest
level of information on any host attached to the network and the
lowest clearance of a user that could potentially get access to
that information. Depending on the characteristics of the network,
this risk index could be larger than either






 • 1. or 2. above. The worst case scenario occurs when some users
have lower clearances than the level at which the network backbone
is physically protected. For example, there are currently plans
to allow some uncleared users on the DISNET segment of the DDN
[22] which will be physically protected at the Secret level. In
that case, the risk index for the bypass works the opposite of
the normal case:  the ciphertext side will be the higher of the
two ratings.
 • The subsystem which performs access control and key distribution
must




also be concerned with this risk range since improper key distribution
could lead to compromise across the entire network. An erroneous
distribution could potentially permit the lowest cleared user
to access the highest classification of information.
LIST OF REFERENCES


 • 1. Department  of Defense  Computer  Security  Center,  Computer
 Security Requirements - Guidance for Applying the Department
of Defense Trusted Computer System Evaluation Criteria in Specific
Environments, 25 June 1985. CSC-STD~03-85
 • 2. Department of Defense, Department of Defense Trusted Computer
System Evaluation Criteria, 15 August 1983. Department of Defense
5200.28-STD
 • 3. National Computer Security Center, Trusted Network Interpretation
of the Trusted Computer System Evaluation Criteria, Version 1,
July 1987. NCSC-TG-
 • 005
 • 4. Department of Defense, Security Requirements for Automative
Data Processing (ADP) Systems, March 1988. Department of Defense
Directive 5200.28
 • 5. National Computer Security Center, Trusted Product Evaluation,
A Guide for Vendors, draft 1 March 1988 (or most recent edition).
NCSCTG~02, Version-
 • 6. National Security Agency, Information Security Products
and Services Catalogue, (quarterly updates).
 • 7. National Institute of Standards and Technology, United
States Department of Commerce, Guideline for Computer Security
Certification and Accreditation, 27
 • September 1983. FIPS PUB 102
 • 8. V. A. Ashby, Thomas Gregg, and Annabelle Lee, "Security
Approach for Rapid Prototyping in Multilevel Secure Systems,"
Fifth Annual Computer Security Applications Conference, December
1989.
 • 9. International Standards Organization, Information processing
systems - Open Systems  Interconnection  -  Basic  Reference
Model,  15  October  1984.
 • International Standard 7498
 • 10. Defense Intelligence Agency, Security Manual for the Uniform
Protection of Intelligence Processed in Automated Information
Systems and Networks (U), Supplement to Director of Central Intelligence
Directive (DCID) 1/16 (U), SECRET, 19 July 1988.
 • 11. National Institute of Standards and Technology, United
States Department of Commerce, Guideline for Automatic Data Processing
Risk Analysis, August
 • 1979. FIPS PUB 65
 • 12. T. E. Bell, "Managing Murphy's Law: Engineering a
Minimum-Risk System," IEEE Specrtum, pp. 2i27, June 1989.
 • 13. National Computer Security Center, Proceedings of the
1988 Computer Security Risk Management Model Builders Workshop,
Fort Meade, MD, May 1988.
 • 14. Sammy Migues, "A Guide to Effective Risk Management,"
Third Aerospace Computer Security Conference Proceedings, December
1987.
 • 15. Carl E. Laudwehr and H.O. Lubbes, An Approach to Determining
Computer Security Requirements for Navy Systems, 13 May 1987.
 • 16. International Standards Organization, Information Processing
Systems - Open Systems Interconnection - Basic Reference Model
- Part 2:  Security Architecture, October 1988. International
Standard 7498-2-1988(E)
 • 17. Ingrid M. Olson, Eugene F. Troy, Milan S. Kuchta, and
Brian W. McKenney, "Disclosure Protection of Sensitive Information,"
13th National Computer Security Conference Proceedings, 1A October
1990.
 • 18. Robert W. Shirey, "Defense Data Network Security
Architecture," Computer Communication Review, April 1990.
 • 19. T. M. P. Lee, "Statistical Models of Trvst:  TCB's
vs. People," IEEE Symposium on Security and Privacy, 1989.
 • 20. Jonathan K. Millen and Martin W. Schwartz, "The Cascading
Problem for Interconnected Networks," Fourth Aerospace Computer
Security Applications Conference Proceedings, December 1988.
 • 21. R. W. Shirey and S.I. Schaen, "ARCHWAY Program Preliminary
Planning," MTR~7W00093~2, The MITRE Corporation, December
1987. Not currently in the public domain.
 • 22. G.  R.  Mundy  and  R.  W.  Shirey,  "Defense  Data
 Network  Security Architecture," MILCOM `87 Proceedings,
21 October 1987.





ACRONYMS



ADP Automatic Data Processing


AIS  Automated Information System


ASD  Assistant Secretary of Defense


AUTODIN  Automated Digital Network


BI   Background Investigation


C    Confidential


C&A  Certification and Accreditation


COMPUSEC  Computer Security


COMSEC Communications Security


COTS Commercial~ffThe-Shelf


CPU  Central Processing Unit


CBS  Central Security Service


CI   Command, Control, Communications, and Intelligence


CSSI Computer Security Subsystem Interpretation


DAA Designated Approving Authority


DAC Discretionary Access Control


DCA Defense Communications Agency


DDN Defense Data Network


DIA Defense Intelligence Agency


DISNET  Defense Integrated Secure Network


DOD Department of Defense


DODD  Department of Defense Directive


DOS Denial of Service


E3  End-to~nd Encryption


ENQ Enquiry


EPL Evaluated Products List


FIPS PUB Federal Information Processing Standards Publication


GOSIP  Government 05I Profile


I&A  Identification and Authentication


INFO SEC   Information Security


IPC  Inter-Process Communication


150  International Standards Organization


1550 Information System Security Officer


JCS Joint Chiefs of Staff


LAN Local Area Network


MAC Mandatory Access Control


MLS Multilevel Secure


MOA Memorandum of Agreement


MOR Memorandum of Record


N Not Classified but Sensitive


NACS National Communications Security Instruction


NCSC National Computer Security Center


NDI  Non-Development Item


NIU  Network Interface Unit


NSA  National Security Agency


NSAD Network Security Architecture and Design


NSAP Network Service Access Point


NTCB Network Trusted Computing Base


0SI  Open System Interconnection


OT&E Operational Test and Evaluation


PDS  Protected Distribution System


PDU  Protocol Data Unit (a.k.a. packet, datagram)


POSIX Portable Operating System Interface for Computer Environments


RFP Request for Proposal


RI Risk Index


S SECRET


SBI Special Background Investigation


SCI Special Compartmented Information


SDNS Secure Data Network System


SH System High


SlOPESI Single Integrated Operational Plan-Extremely Sensitive
Information


ST&E Security Test and Evaluation


STS Single Trusted System


TCB Trusted Computing Base


TCP/IP Transmission Control Protocol/Internet Protocol


TCSEC Trusted Computer System Evaluation Criteria $


TEMPEST  (Not an acronym)


TNI  Trusted Network Interpretation


TNIEG TNI Environments Guideline


TS TOP SECRET


TSAP Transport Service Access Point


WAN  Wide Area Network


U.S. GOVERNMENT PRINTING OFFICE : 1990 O - 274-353 : QL 3



n